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corresponding pages of memory. To protect the pages of 
memory, a user program first requests that token controlled 
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space and that a corresponding user token be returned by the 
processor. The user program stores the user token for later 
use when accessing the protected pages. When the user 
program requests access to the protected pages, the proces- 
sor matches the user token with a system token to obtain a 
token-accessible view in the system space of the protected 
pages. 
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VIRTUAL STORAGE COMPUTER SYSTEM 
HAVING METHODS AND APPARATUS FOR 
PROVIDING TOKEN-CONTROLLED 
ACCESS TO PROTECTED PAGES OF 
MEMORY VIA A TOKEN-ACCESSIBLE 
VIEW 

CROSS-REFERENCE TO RELATED 
APPLICATION 

This application is a continuation-in-part of application 
Ser. No. 08/050,694 filed Apr. 19, 1993, now abandoned. 

BACKGROUND OF THE DISCLOSURE 

1. Field of the Invention 

The invention relates to apparatus for providing access to 
memory storage in computer systems, and more particularly, 
to apparatus and concomitant methods of providing access 
protection to specific pages of virtual memory space. 

2. Description of the Prior Art 

Most modern computer systems, particularly mainfr ame 
computers, employ high speed random access memory 
(RAM) circuits as main memory and relatively slow mass 
memory devices, such as hard disk or magnetic tape drives, 
as auxiliary (mass) storage. The disparity in access times 
between random access memory and disk or tape drives is 
substantial and severe, with the former having access times 
often ranging in the order of at least tens of milliseconds. 
Given this disparity, user programs are not executed from 
auxiliary storage, but rather are transferred therefrom into 
main memory for execution therein. 

In practice, consideration of cost physical circuitry size 
and/or power requirements frequently limit the amount of 
RAM memory that is used in implementing a main memory 
to a finite real address space which is often substantially less 
than the maximum address space of a processor that is to 
access this memory. For example, a processor that operates 
with a 31 bit virtual address word, which inherently pos- 
sesses the capability of separately addressing 2 31 (over 2 
billion) bytes, may often operate with as little as a few 
million bytes (Mbytes) of actual RAM. To provide suffi- 
ciently rapid execution speeds, the available RAM must be 
shared among all current user programs that are executing 
on the processor as well as with a resident portion of the 
operating system used by the processor. Unfortunately, 
RAM is rarely, if ever, sized sufficiently large to fully 
accommodate all the instructions and data that form each 
such user program and the resident portion of the operating 
system. 

However, it was recognized quite early in the art that, 
through normal operation of instruction fetches, stack and 
data accesses, and standard programming techniques, most 
program instructions possess a rather good spatial locality of 
reference. This means that, at memory location x in an 
executing user program, this program will exhibit a strong 
tendency to interact within relatively small time delays with 
different but nearby memory locations, such as locations 
x+1, x+2 and so on. This behavior, often involving preced- 
ing instructions, e.g., locations x-1, x-2 and so on. is clearly 
evident in loops and other similar program structures. 
Although the organization of external data is often as 
constrained by the architecture of the processor as are the 
stack and instruction accesses, such data, particularly arrays, 
are stored in contiguous memory locations and, as such, 
often exhibit spatial locality. In this regard, certain pro- 
grammed operations, such as illustratively clearing, 
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transposing, adding or array multiplication, that at any 
instance utilize one element of an array will likely access 
other elements of the array within a short time. Similarly, the 
art has recognized that instructions and data often exhibit a 

5 good temporal locality of reference as well, Le., where the 
same memory location is repeatedly accessed over time. 

Given these recognitions regarding spatial and temporal 
localities, the art has turned to and now widely uses a 
number of memory techniques that attempt to share a 

io relatively small amount of real memory among a number of 
currently executing user programs, each of which is capable 
of addressing a much larger memory space. These memory 
management techniques are generally known as virtual 
memory techniques. 

15 One such virtual memory technique is paging. Here, in 
essence, different finite portions, ie,, "pages", of memory 
data (collectively including both instructions and data 
values) for each user program, rather than all the memory 
data for that program, are successively copied ("swapped") 

20 from auxiliary storage into main memory and then used for 
current program execution. Owing to spatial and temporal 
localities, the main memory contains pages of memory data 
that not only possess memory locations that have just been 
recently accessed but also locations that are expected to be 

25 subsequently accessed within a very short delay time. With 
a well designed paging system, the vast majority of memory 
access time should be spent accessing memory data located 
within pages previously copied into main memory with 
* relatively little access time being spent in copying new 

30 pages of memory data from auxiliary storage. 

Specifically, whenever the processor attempts to access 
memory while executing a user program, the processor 
issues a so-called 'Virtual address" for a desired memory 

3S datum that is to be accessed. The size of the virtual address 
is generally only limited by the maximum address space of 
the processor that is allowed for program usage. By contrast, 
a so-called "real" or '•physical" address is used to directly 
access memory in order to locate the desired memory datum 

^ stored therein. Since the virtual address of any given 
memory datum is not necessarily the same as its correspond- 
ing real address, a translation facility, provided by the 
operating system working in conjunction with memory 
access hardware and generally transparent to any executing 

45 user program, translates each virtual address issued by the 
processor to a corresponding real address prior to accessing 
main memory in order to obtain this datum. 

Both virtual and real memory space are divided into fixed 
sized areas or segments, each of which is, in turn, divided 

50 into a number of contiguous pages. Each page is formed of 
a predefined number of memory locations, typically ranging 
from 2 to 4 kbytes. Though pages for any program are 
contiguous in virtual memory; the corresponding physical 
pages for that program, being swapped into and out of main 

55 memory as required by the operating system during 
on-going program execution, tend to be randomly, scattered 
throughout main memory. A physical page in main memory 
is often referred to as a "page frame". 
The random locations of page frames in main memory 

go necessitates that the operating system maintain address 
translation, specifically and illustratively segment and page 
software tables and an address translation process which 
utilizes these tables for use in translating virtual to real 
addresses. These tables and the translation process coUec- 

65 tively form the address translation facility. For each virtual 
page copied from auxiliary storage as a page frame into main 
memory, the address translation tables store the page frame 
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address that corresponds to each virtual page address. Inas- In practice, the operating system assigns each user pro- 
much as memory locations within any page, whether virtual gram a key. The key is stored in a program status word 
or real, are contiguous, then through these tables, a virtual (PSW) for that particular program. The PSW contains infor- 
address located within such a virtual page can be mapped mation about each user program presently executing and is 
into a physical address of a location residing in main 5 stored in a so-called special register within the processor to 
memory. facilitate repeated access by the operating system during 

Given this virtual addressing scheme, whenever the pro- program execution. The specific information carried by the 

cessor attempts a memory access for a given memory datum PSW, other than the key, is irrelevant to our page protection 

during execution of a user program, the processor issues a technique. Whenever a user program issues a valid virtual 

virtual address for that datum The datum may currently 10 address, the translation facility translates the virtual address 

reside in main memory or it may not. If the datum resides in into a page frame and then the processor compares the key 

the main memory, the virtual to real address correspondence in the PSW of that program to the key associated with that 

for that datum exists in the page and segment tables. As page frame. If the keys are identical, the operating system 

such, the address translation process, upon accessing these permits access to that page frame. However, if the keys do 

tables, extracts the physical address of the datum and 15 not match, the operating system terminates the user program 

thereafter applies this address to the main memory. Once this which has attempted an inappropriate memory access. In 

datum has been accessed, user program execution proceeds this manner, a user program cannot inadvertently access 

accordingly. (either to read or write) that page frame. Of course, the 

If, however, the desired datum does not currently reside operating system, having key zero, may access any key 

within the main memory because a page containing that 2 o P rotected P 8 ^ frame. 

datum has not yet been swapped into main memory, then no Another memory protection technique protects so-called 
valid entry for its associated virtual page exists in the page low address memory space. To maintain a portion of 
and segment tables. As such, the datum must be retrieved memory that is only alterable by systems programs, the 
from auxiliary storage. Accordingly, the address translation processor uses a low address protection technique, 
process, upon accessing these tables using that virtual 2 5 Typify, the first 5 12 bytes of memory space, known as the 
address, produces a page fault. At this point, interpretation low address portion of memory, are reserved for routines 
of a current instruction (which caused the page fault) halts, which interact with hardware, such as control timer 
the current state of the processor is saved and the processor interrupts, supervisor calls, program checks, machine 
transfers execution to a software page fault handler. Rather checks, and input/output interrupts. The low address pro- 
than accessing and copying only the desired datum from 30 tection technique permits user programs to fetch from the 
auxiliary storage, the page fault handler translates the low address portion of memory space. However, user pro- 
incoming virtual page address and, then, through input/ grams are not permitted to store to that memory space, 
output controllers) for an appropriate mass storage device Another memory protection technique protects individual 
(s), copies an entire page containing that desired datum from pages of memory. Using a so-called page protection 
auxiliary storage as a page frame into main memory. 35 technique, an entire page of memory can be protected from 
Thereafter, the fault handler updates the segment and page either inadvertent or intentional memory alteration, 
tables accordingly with a real address for this page. Execu- Typically, the page protection technique is utilized to protect 
tion then returns from the fault handler to the address memory space that is not protected by low address protec- 
translation process which, in turn, accesses the desired tion. Consequendy, page protection enables the processor to 
datum from the newly copied page. When appropriate, the 40 protect individual pages of memory within an otherwise 
fault handler, will subsequently resume execution of the unprotected segment of memory. Page protection is used in 
current program instruction that generated the page fault addition to key protection and provides protection of a 
The processor must ensure that one user program does not memory location from being inadvertently altered by other 
intentionally or accidentally use the pages presently used by user programs as well as the operating system. As noted 
another user program or the operating system. The processor 45 above, key protection does not protect page frames from 
performs such memory protection using one or more pro- alterations accomplished by the operating system, i.e., a 
tection techniques. Typically, main memory is protected by program using key zero. 

three different protection techniques: storage key protection, Page protection is implemented by setting a page protec- 
low address protection, and page protection. Each protection tion bit within a page table entry. The page protection 
technique is discussed below. so technique blocks a program from storing information to a 
To facilitate storage key protection, as each page frame is page that corresponds to a page table entry having a set 
copied into main memory, the processor associates the page protection bit When the protection bit is zero, the processor 
frame with a hidden byte known as a storage protection key permits both fetching and storing to a page frame; when the 
(hereinafter referred to as a key). The key contains eight bits protection bit is one, only fetching from that frame is 
(one byte); however, only the first four bits are used as the 55 permitted. In operation, during address translation, the trans- 
key itself. The remaining four bits of the key are used to lation routine tests the status of the protection bit for the 
indicate page frame status, and are irrelevant to this discus- page frame to which a virtual address points. If a program 
sion. As a result of the limited number of bits used for the attempts to store to a location having a set protection bit, 
key. there are only 16 different keys available. Of these 16 e.g., a value of one, the processor interrupts execution of the 
keys, key zero is reserved for the operating system. Keys 1 60 program. 

through 15 are assigned to user programs (or individual Typically, during user program execution, the program 
jobs) as each is executed by the operating system Since will request the processor to protect one or more pages of 
there are only 15 available keys, multiple user programs may memory. In response, the processor will set the page pro- 
be assigned the same key. The key, associated with a tection bit for the page frame that the program previously 
particular user program(s) that stores to a given page frame, 65 accessed. Consequently, the program requesting the page 
is itself stored in a register as a hidden byte associated with protection, as well as all other programs having the same key 
that page frame. or key zero, may only fetch information from the protected 
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page. Subsequently, the program that requested page pro- Id operation, the user program issues a special instruction 
tection may wish to write to the protected page. To do so. the that retrieves the previously stored token from its register, 
processor must first change the page protection bit to zero. The user program then presents a virtual address of the 
then the program alters information within the previously datum in the protected page which the instruction intends to 
protected page. While the protection bit is set to zero, the 5 alter and the token to an address translation and protection 
entire page is open to inadvertent alteration by other pro- verification process. This process translates the virtual 
grams which have the same key as the program that address into a real address in a manner that is common in the 
requested page protection. In addition, the operating system, art If the page in which the real address is located is not 
having key zero, may inadvertently write to the presently protected, the real address is used to access the datum at that 
unprotected page. Inadvertent storage, known as overlay, 10 address and alter it in the manner requested by the special 
typically occurs when a power failure or programming error instruction. On the other hand, if the real address is con- 
causes a program to write to an incorrect address. " a protected page, the process uses the PVST and 
Thus, a need exists in the art to provide a memory space *VCT to detennta a token associated with the protected 
protection technique which allows a program that has ^ 

rln^ctoA ™?t»,*:™ *~ w~*u ™h on A „J:** ^ instruction, the instruction can alter the contents of the 

requested page protection to » r^m read and wnteinforrration 15 ^ A the ^ Ho tf 

tojtspra^ matdu ^ atin tem tenninates ^ for 

overlay. Such a memory protection technique must be com- attempting an unauthorized memory access. In this Tmanner, 

patible with present virtual memory storage systems and our token controlled pa g e protection technique protects 

their present protection techniques, i.e.. storage key pag es of memory from alteration by all programs not 

protection, low address protection and page protection. 20 possessing an appropriate token. 

SUMMARY OF THE INVENTION According to another aspect of our invention, the com- 

A ... * * . . * . 1 puter system creates a second virtual storage area with a 

Accordingly, an object of our invention is to provide a ^cond virtual address in response to a token protection 

virtual memory storage protection technique that permits a r st ^ second virtual storage m corresponds to the 

program to protect an area of memory and to subsequently M fast virtual storage area, i.e. the real storage area. The 

store information to the protected area. sy$tem establishes the protected view of the real storage area 

Another object of our invention is to provide such a with respect to the first virtual address, and establishes the 

technique that maintains overlay protection against user token-accessible view of the real storage area with respect to 

programs storing to the protected page while a user program the second virtual address, A token table holds the system 

that requested page protection for a particular page is storing 30 token, the first virtual address and the second virtual address 

information to that protected page. in a table entry. When accessing the real storage, the user 

Yet another object of our invention is to provide such a program uses the user token to request a pointer to locate a 

protection technique which is compatible with presently corresponding system token in the token table and to retrieve 

available protection techniques used by virtual memory a pointer virtual address corresponding to a user virtual 

systems. 35 address provided with user token. A token verification 

These and other objects are achieved in accordance with control generates the pointer virtual address and passes it to 

our present invention by providing a virtual storage com- the user program if the user virtual address is calculated to 

puter system having token controlled storage protection. The be in the first virtual storage area. A program exception is 

computer system includes a data processor for executing a requested if the user virtual address is not in the first virtual 

user program, a real storage providing a real storage area 40 storage area. An isolating storage area is created contiguous 

with a real address and a virtual storage providing a first with the second virtual storage area. A protected view of real 

virtual storage area with a first virtual address. The user storage area is established with respect to the virtual address 

program has a protection request instruction for requesting of the isolating storage area, 

that token controlled storage protection be provided for the BRIEF DESCRIPTION OF THE DRAWINGS 

real storage area via said first virtual address and that a 45 _ , . „ 

corresponding user token be returned for use by the user ™ e tea ^ s rf P"?** invention can be readily 

program when requesting access to the real storage area. The ^mtaoA by considering the following detailed descrip- 

system includes an address translation apparatus, responsive *° n , m con J UIlction with accompanying drawing, in 

to an access request, which translates a virtual address into wmcn: 

a corresponding real address. A token protect apparatus, 50 mGt 1 ^picte a high level block diagram of various 
responsive to the protection request instruction, generates components for translating virtual to real addresses in virtual 
the user token and a corresponding system token. An area memory computer system 99 in a general purpose computer 
protection apparatus establishes a protected view and a m & for implementing, in accordance with one embodiment 
token-accessible view of the real storage area via the address °f our invention, a token controlled page protection tech- 
translation means. 55 mo i ue i 

According to one aspect of our token controlled page HG. 2 depicts a detailed blodcdkgram of process 220 for 

protection technique, the computer system assigns a token to providing address translation and page protection vexifica- 

a user program when the program requests a page of tion for computer system 99 of FIG. 1; 

protected storage space. The token is stored in a register such FIG. 3 a flow chart of our inventive token controlled page 

that the program can access the token when the program 60 protection routine 465 as it would be executed in computer 

needs to alter the contents of the protected page. As the token system 99 of FIG. 1 ; 

is assigned, the operating system builds a protection verifi- FIG. 4 depicts a high level block diagram illustrating the 

cation segment table (PVST) and a protection verification functional components of a token controlled protection 

page table (PVFT). The PVST contains entries which point system in accordance with the present invention; 

to particular page origins that are used as addresses to PVFT 65 FIG. 5 diagramatically illustrates pages of data located in 

entries. The PVFT contains tokens as entries corresponding virtual and real storage in accordance with the embodiment 

to each protected page. illustrated in FIGS. 6-9; 
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FIG. 6 depicts a block diagram illustrating an alternate in order to obtain a memory datum (collectively including 

embodiment of our invention in the state of obtaining token both instructions and data values) stored thereat. In execut- 

controlled protection for an area of storage; ing certain instructions or when the address translation 

FIG. 7 is a flow chart showing a sequence of process steps facaitv 15 tabled, processor 100 may operate in a real 

performed by the embodiment of FIG. 6; 5 addressing mode thereby generating a real memory 

™~ « , . ..... ... . . t _i . address — for which address translation is not required. 

FIG. 8 depicts a block diagram illustrating the embodi- HeDCCj fe purposes of mustration ^ for simplif y mg me 

ment of FIG. 6 executing instructions including an instruc- following discussion, this discussion will hereinafter assume 

tion for obtaining access to a protected area of storage; and ^ processor X 00 is operating in a virtual addressing mode. 

FIG. 9 is a flow chart showing a sequence of process steps ^ The virtual address space available for a user program is 

performed by the embodiment of FIG. 8. only limited by the maximum address space for the proces- 

To facilitate understanding, identical reference numerals sor. However, the virtual address does not necessarily equal 

have been used, where possible, to designate identical the real address in main memory 110 at which this datum is 

elements that are common to the figures. actually stored. The real address space is limited, not by 

processor 100, but rather by the capacity of main memory 

DETAILED DESCRIPTION 15 no. Accordingly, address translation and protection verifi- 

After reading the following description, those skilled in cation, facility 105 is used to translate the virtual address 

the art will clearly realize that our invention could be used P r0Vld £ by pr<^sor 100, over path 130 into a real or 

in conjunction with nearly any virtual memory computer to £«™ s ** 15 a ?P Le * ™ P a * ™ '? ™* 

improvei^^^^ 20 = 

appropriate and for purposes of specific illustration, our IC$um m ^turn generated by main memory U0 is 

invention will discussed below in the context of use in an meQ routedi yia ^ 215 * back to processor 100 for subse- 

IBM model 390/Enterpnse Systems Architecture (ESA) quent use by i nstruct ion execution unit 120 during program 

general purpose mainframe computer manufactured by the execution. 

International Business Machines Corporation of Armonk, 25 Alternatively, if the page frame is page protected, pro- 
New York (IBM is a registered trademark of the Interna- cessor 100 must presen ^ along path 125, a protection token 
tional Business Machines Corporation). (hereinafter referred to as a "token") to translation and 

Now, to fully appreciate the teachings of our present protection verification facility 105. This token is compared 

invention, we will discuss the rudiments of paged memory to a token associated with the protected page frame, and if 

systems and their respective page protection techniques that 30 the tokens match, the data in the page frame can be altered 

can be used in any general purpose mainframe computer. by the program possessing a correct token even though that 

Additionally, we will include a detailed discussion of our page is page protected. In this manner, certain programs can 

invention, particularly as it could be used in conjunction be authorized to alter protected pages without removing the 

with an illustrative computer, such as an IBM model 390/ protection for the entire page. If a correct token is not 

ESA mainframe computer. 35 presented by processor 100, the address translation and 

Specifically, FIG. 1 depicts a high level diagram of protection verification facility issues, along path 135, a 

various components for performing memory access opera- protection verification exception. In response thereto, the 

tions using a token controlled page protection technique, and operating system will terminate the program which 

specifically including those components which translate requested the unauthorized access. The details of how the 

virtual to real addresses and are typically used in a general 40 tokens are assigned and used are discussed below, 

purpose mainframe computer. Additionally, the diagram Address translation and protection verification facility 

includes components for determining whether a program 105 is often implemented using a combination of well 

requesting to stare information into an otherwise page known specialized hardware, microcode and software. This 

protected page frame can do so without causing a protection software generally forms part of the operating system (not 

violation exception. As shown, these components include 45 shown but well known) that is executed by instruction 

processor 100 which contains address translation and pro- execution unit 120 to control the operation of the computer, 

tection verification facility 105, (shown separate from the The usage of the address translation and protection verifi- 

processor for clarity of illustration), main memory 110 and cation facility, particularly if the facility is well designed, is 

auxiliary (mass) storage 115. Additionally, processor 100 typically transparent to the execution of user programs by 

executes an operating system (not shown but well-known in 50 processor 100 and generally, but not always as will be 

the art). Processor 100, main memory 110 and auxiliary discussed below, imparts relatively little processing delay to 

storage 115 are all implemented in specialized hardware. the execution time of these programs. 

Main memory 110 is typically implemented using high Address translation and protection verification facility 

speed random access memory (RAM) circuits, while auxil- 105 contains address translation and protection verification 

iary storage 115 is typically formed of magnetic tape, hard 55 process 140 which is typically implemented in microcode; 

disk drives and specially allocated portions of main memory fault handler 205 which is usually implemented in software 

known as "expanded storage". The disparity in access times as part of the operating system; and address translation 

between main memory 110 and auxiliary storage 115 is segment and page tables 150 and 160, and protection veri- 

substantial and severe, with the former having access times fication segment and page tables 175 and 185 — all of these 

ranging on the order of tenths of microseconds or less while 60 tables typically being within main memory 110. Inasmuch as 

the latter has access times often ranging on the order of at tables 150, 160, 175 and 185 are an integral part of address 

least tens of milliseconds. translation and protection verification facility and are 

User programs, also known as application programs, are accessed by address translation and verification process 140, 

executed by processor 100 and specifically by instruction then, for ease of understanding, these tables have been 

execution unit 120 contained therein. During the execution 65 shown within facility 105. 

of a user program using a paged memory system, processor In operation, address translation segment table (XTST) 

100 issues a virtual memory address of a memory location 150 and address translation page table (XTPT) 160 contain 
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a memory mapping which converts a virtual page address permits access. However, if the keys do not match, the 

into a page frame address for each user currently executing operating system terminates the user program which has 

a program on processor 100. The operating system first attempted an inappropriate memory access. In this manner, 

determines whether segment and page tables exist for the one user program cannot inadvertently access a page frame 

user program sending a virtual address to the processor. If 5 having a key assigned to another user program. However, 

these tables do not exist, the operating system then builds the limited number of available keys forces the operating 

these tables within main memory 110 and stores these tables system to assign the same key to different user programs. Of 

within allocated page frames in main memory. Each such course, the operating system (key zero) may access any key 

user is assigned one ATST. A register (not shown but well protected memory space. 

known) located within processor 100 is also assigned to that 10 After me toy is assigned and ATST and ATPT have been 

user and contains the starting real address (also referred to built the user program can request that certain page frames 

as ATST origin or simply "ATSTO") of the associated ATST De P a S e protected. For those protected pages, the operating 

assigned to this user. The ATST. as will be explained in detail system sets a bit in the ATPT entry that indicates that the 

below, contains entries that point to the origins of address P a S e corresponding to that entry is protected. Traditionally, 

translation page tables (ATPT). A user has at least one and 15 a user "^f ^ formation in i those protected 

sometimes multiple ATPTs. Each ATPT contains a corre- P a f s unle f me user program guested that the operating 

spending page frame address for each virtual page address ***** &st remov u e P"*?*™- 

stored within the table. Each entry within the ATST and 0ur *vention, however, permits the user program that 

ATPT(s) for a given user contains a bit, i.e.. an "invalid bit" pr 5f pages * ^ mformatl ^ n merem 

wWchindi^ 20 ^LTrTof ^"SJSSfSS" I^lf^Z 
, ^ ... 4 , - v_ . , .1 T- j inventive form 01 page protection, the operating system, 
currently usable), or not If an ^ entry ■ « not -currently vahd, fte user ^ ^ ^ protection, builds 
then, in the absence of being initialized, that entry has no protection verification segment table (PVST) 175 and pro- 
valid meaning and is not used by the operating system. tection verification page table (PVFT) 185. The operating 
Alternatively, if an entry is valid, then the operating system S y Ste m builds these tables within main memory 110 and 
is subsequently able to use this entry during address trans- 25 stores these tables within page frames allocated to the 
lation. Since the address of any memory datum located address translation and protection verification facility. Of 
within both a virtual page and its corresponding page frame, course, if the user program does not request any protected 
relative to the origin of the associated page, is the same for pages, the PVST and PVFT are not built, 
both the virtual and real pages, only the virtual page address Once the PVST and PVPT have been built, the operating 
bits in a virtual address need to be translated into page frame 30 system assigns each protected page a token. Each token 
address bits. The low order address bits that provide address- contains 16 bits, thus, providing 65,536 unique tokens. Each 
ing within a page, i.e., byte index bits, are merely copied user program request for page protection is typically 
from the virtual to the real addresses, as described in detail assigned a unique token, Le., one of the 65,536 available 
later. tokens. Therefore, a single user program which requests 
After a user instructs the operating system to begin 35 page protection at different times during program execution 
executing a user program, the operating system initiates a generally is assigned a different token for each such request 
conventional key protection technique. To facilitate key In this manner, groups of pages may be assigned one 
protection of main memory 110, the operating system particular token and another group of pages may be assigned 
assigns that user program a key. The key contains eight bits; a different token, though all the protected pages are accessed 
however, only the first four bits form the key itself. 40 by a single user program. Typically, each group of pages 
Therefore, there are typically only 16 different keys contains contiguous pages in real memory space. As other 
available, e.g. 2 4 . Of these 16 keys, key zero is reserved for user programs request page protection, each request is 
the operating system. Keys 1 through 15 are assigned to user assigned a different token. The assigned tokens are stored in 
programs (or individual jobs) as each is executed by pro- special registers that are accessible to the token's associated 
cessor 100. In this manner, the key associated with a user 45 user program. Additionally, the operating system stores each 
program that stores a page frame is also assigned as the key token as an entry in the PVFT, 

for that page frame. The remaining four bits of the key are The operating system assigns one PVST to each user 

used to indicate page frame status; a use that is irrelevant to program A register (not shown but well known) located 

our invention. within processor 100 is also assigned to that program and 

In practice, the operating system assigns each user pro- so contains information pointing to a memory space which 

gram a key. The key is stored in a program status word stores the starting real address (also referred to as a PVST 

(PSW) for that particular program. The key is also stored in pointer) of the associated PVST assigned to this user. The 

a memory location in main memory. This memory location PVST, as will be explained and shown in detail below, 

is associated with the page being protected by the key contains entries that point to the origins of PVFTs. A user 

protection technique. The PSW contains information about 55 program that has requested page protection has at least one 

each user program presently executing in processor 100 and and sometimes multiple PVFTs. Each PVFT contains a 

the PSW is stored in a so-called special register within the corresponding token for each virtual page address that is 

processor to facilitate repeated access by the operating page protected. Each entry within the PVST contains a hit, 

system during program execution. The specific information ic, an "invalid bit" which indicates whether that entry is 

carried by the PSW, other than the key, is irrelevant to our 60 **valid" i e meaningful, or not If an entry is not currently 

inventive page protection technique. In operation, whenever valid, then, in the absence of being initialized, that entry has 

a user program issues a valid virtual address, the translation no valid meaning and is not used by the operating system, 

facility first translates the virtual address into a page frame. Alternatively, if an entry is valid, then the operating system 

Thereafter, the operating system compares the key in the is subsequently able to use this entry during protection 

PSW of that program to the key associated with that page 65 verification. 

frame, i.e.. the key in a memory location associated with that To utilize the protection verification process and be able 

page frame. If the keys are identical, the operating system to alter information in an otherwise protected page, the user 
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program must use special instructions that evoke the pro- 
tection verification process. If these special instructions are 
not used and storage to a protected page is requested using 
traditional instructions, the operating system will deny that 
storage function. However, by using the special instructions, 
a user program can retrieve its assigned token and use that 
token to alter the contents of a protected page having a 
matching token. Since our inventive page protection tech- 
nique is only evoked when these special instructions are 
used, the following discussion will be limited to the use of 
these instructions. The specific details of the special instruc- 
tions are discussed below. 

Specifically, the special instructions accomplish two 
tasks: (1) perform a particular function such as storing to a 
page protected memory address and (2) retrieve a token 
from a register such that the function can be performed. For 
example, a traditional "store" instruction has the following 
format: 

TABLE 1 



OPCODE 


Ri 


x 2 




I>2 



bits: 0 



8 12 15 20 31 



where: 



OP CODE is an operation code, typically a 
hexidecimal Dumber, that defines the 
function to be performed, 

Ri is a particular register; and 

X2, Bj and D2 are registers whose combined 
contents define a virtual address. 



10 



15 



25 



30 



Functionally, a traditional "store" instruction accesses 
register R 4 and stores the contents therein in main memory 
at the virtual address defined by X 2 . B 2 « D 2 . Of course, the 
virtual address must be translated to a real address to 
facilitate storage. If that real address is within a protected 
page, this instruction would not be completed. 

To utilize our token controlled page protection technique, 
the user program uses special instructions having unique op 
codes. The following example of a special instruction used 
to evoke the token controlled page protection technique is 
meant to be illustrative. Those skilled in the art will realize 
that any instruction used to alter the contents of a page of 
memory can be modified to facilitate utilization of our 
invention. 

An illustrative implementation of these special instruc- 
tions use what is known as a "double register pair". For 
example, one such special instruction, known as a "store 
with token" instruction, has the same format as the tradi- 
tional "store" instruction shown in Table 1. However, the 50 
particular op code would cause a "store with token" function 
to be performed rather than a traditional "store" operation. 
This function defines B 2 as a double register pair, e.g., 
registers B 2 and B 2+1 . As such, when the instruction is 
executed the contents of register B 2 and its associated 55 
register B 2+1 are retrieved. The content of register B 2+1 is a 
token. Thus, the instruction can present to address transla- 
tion and protection verification process 140 a token, i.e. the 
contents of register B 2+i , and a virtual address defined by the 



translates the virtual address to a real address which is page 
protected, determines a token associated with the protected 
page from the PVFT, and compares the token associated 
with the protected page with the token supplied by processor 
100. If the tokens match, the content of register Rj is stored 
in main memory at a real address corresponding to the 
virtual address. If the tokens do not match, the operating 



system deems the user program has attempted an unautho- 
rized memory access and terminates the user program which 
executed the "store with token" instruction. 

Now, continuing with the discussion of FIG. 1, once the 
operating system builds the various segment and page tables 
or confirms their existence for the user program, the oper- 
ating system begins actual program execution. Inherent in 
this execution is address translation. Although typically 
transparent to the user program, each virtual address issued 
by instruction execution unit 120 is first translated, by 
facility 105. during program execution into a page frame 
address for subsequent use in accessing main memory 110. 
In particular, after a virtual address is issued by the 
processor, that address is routed, as symbolized by path 130, 
to address translation and protection verification process 140 
located within facility 105. Process 140 accesses the AT ST 
and XTPT for the current user to locate the specific page 
table entry for the incoming virtual page address. If the 
invalid bit in an entry accessed from the ATST is set to zero, 
20 then this entry is currently valid for this user. Then, using, 
inter alia, a page table origin stored within this segment table 
entry, process 140 accesses a specific entry in an associated 
ATPT and reads the corresponding page frame address from 
this entry. If the invalid bit contained within this ATPT is set 
to zero and the user has a key which matches the key for this 
page table entry, then this page is valid and accessible for 
this user. This indicates that the virtual page that is being 
addressed has a corresponding page frame residing within 
main memory 110. As such, the page frame address is simply 
read from this page table entry. 

Whether this user program can store to this page is 
determined by the page protection bit within the ATFT entry. 
If the protection bit is zero, the user program may either 
fetch or store to the page. Alternatively, if the protection bit 
is set to one, the user program may only read from the page. 
However, if the instruction execution unit has provided the 
correct token, i.e., matching the token in the PVFT corre- 
sponding to this address, then the user may fetch or store to 
this address within the otherwise protected page. The pro- 
cess of accessing the PVFT to determine a token is discussed 
below in detail. 

While virtual pages are contiguous in virtual address 
space for any user program, corresponding page frames for 
that program, being swapped into and out of main memory 
as required by the operating system during ongoing program 
execution, tend to be randomly scattered throughout main 
memory. Accordingly, each entry in the ATPT contains 
information for generating the complete page frame address 
for that page, e.g., the complete address is formed by 
appending three zeros to the ATFT entry. Hence, with a valid 
page table entry, process 140 obtains the corresponding page 
frame address from the ATPT entry. The low order virtual 
address bits are then appended to this corresponding page 
frame address to yield a real address that is applied, via path 
190, to main memory 110. 

Now, in the event that the accessed entry in either the 
ATST or ATPT for the user contains an invalid bit that is set 
and hence indicates an "invalid" state for that entry, then 
address translation protection verification process 140 issues 
an appropriate interrupt (well known and not shown) to 
signify a respective segment or page table fault. On the one 
hand, for an invalid ATST table entry, this means that an 
associated ATFT, which would be expected to contain an 
entry for the current virtual page address being translated, 
simply does not exist in main memory 110. Since the ATFT 
does not exist, then clearly an expected entry on that table 
for the particular virtual page being translated does not exist 
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as well In this case, the operating system would now build 
the ATPT. Once the ATFT is created, the invalid bits in all 
of its entries would be reset to reflect an invalid condition. 
On the other hand an invalid page table entry indicates that 
a corresponding page frame for the particular virtual page 5 
address being translated simply does not yet exist within 
main memory 110. Therefore, in either situation, as a result 
of just building the ATFT based upon an invalid segment 
table entry or attempting to access an invalid page table 
entry, the operating system realizes that the requested page 10 
does not reside within main memory 110 and issues a "page 
fault". In response to this fault, fault handler 205 obtains the 
missing page from auxiliary storage 115. Specifically, upon 
issuance of a page fault by process 140, this process instructs 
the operating system to halt execution of the current instruc- 15 
tion by instruction execution unit 120. The current state of 
processor 100 is then saved by the operating system. Pro- 
cessor 100 then transfers execution, as symbolized by path 
195, to page fault handler 205. The page fault handler 
triggers certain system software functions to identify 20 
whether there is a copy of the faulted page in the auxiliary 
storage. If a copy of the faulted page is not currently resident 
in the auxiliary storage, a new page frame (normally cleared 
as zeros) is allocated within main memory 110. Proper 
input/output operations are initiated through input/output 25 
controllers) (well known and not shown) associated with 
auxiliary storage 115, and a desired page from the auxiliary 
storage is copied (swapped), as symbolized by dashed line 
210. into a newly allocated page frame within main memory 
110. One or more well known algorithms, which are not 
relevant here, are executed by the operating system to 
identify that specific page frame which is to be allocated. 
Inasmuch as the processor will likely be executing one or 
more other user programs while a page is being swapped 
into main memory 110, execution of the specific user 35 
program that generated the page fault will often not resume 
immediately upon completion of the swap. In this case, upon 
completion of the swap, various well known components 
(well known and not relevant here) of the operating system 
will update the ATFTs for this new page frame, "ready" the ^ 
specific user program and then place that program in a 
dispatchable state from which the program will eventually 
be dispatched to the processor and then resume execution. 
After the tables have been appropriately updated, then the 
fault handling process concludes with execution returning to 45 
process 140, as symbolized by path 200. 

Though the process discussed above, of swapping pages 
from auxiliary storage 115 into main memory 110 in 
response to a page fault does not form part of the invention, 
it has been described at least on a simplified basis, to provide 50 
a full understanding of the overall address translation and 
protection verification process. However, for simplification, 
the following discussion of the token controlled address 
translation process will assume, unless specifically noted 
otherwise, that all virtual pages for which translation is 55 
being requested, have already been swapped into main 
memory 110 and have corresponding entries in ATST 150, 
ATPT 160, PVST 175 and PVPT 185. 

Now, with the above overall description in mind, FIG. 2 
depicts a simplified diagram of a virtual to real address 60 
translation process 220 using our inventive token controlled 
page protection technique. Process 220 could occur during 
ongoing program execution in illustratively an IBM model 
390/ESA mainframe computer. 

In the computer, a user program can employ either a 65 
primary or secondary virtual address space. To the extent 
relevant here, primary virtual addresses utilize a primary 



segment table; while secondary addresses utilize a second- 
ary segment table. Therefore, as contrasted with the descrip- 
tion given above, a user program of this particular computer 
may have two ATSTs: a primary ATST and a secondary 
ATST. The processor in this computer assigns two registers, 
control register 1 labeled as register 225 and control register 
7 labeled as register 230, to a user program during current 
program execution. Registers 225 and 230 respectively hold 
segment table designations (STOs) for translation of primary 
and secondary virtual addresses. The processor uses the 
STDs to form a pointer, as described below, into either the 
primary or secondary ATST. Once the appropriate control 
register is selected, far reasons and in a manner both of 
which are not relevant here, address translation proceeds in 
the same fashion for either ATST. Inasmuch as both of these 
registers store 32 bits and have the same data format; the 
following discussion will primarily refer to register 225 and 
the primary segment table designation (PSTD) stored 
therein. Within this register as given in Table 2 below, the 
highest order bit (bit 0) is a control bit, not relevant here. The 
next nineteen bits (bits 1-19) store the primary segment 
table origin — PSTO (secondary segment table origin, SSTO, 
in register 230). The PSTO, with twelve zeros, appended to 
the right forms a real (or sometimes absolute) address that 
designates the beginning (origin) of this segment table. The 
next five bits (bits 20-24) are not used. The remaining seven 
bits (bits 25-31) store a number that specifies the primary 
segment table length— PSTL in units of 64 bytes, thus 
making the length of the ATST variable in multiples of 
sixteen entries. The length of the primary ATST, in units of 
64 bytes, is one mare unit (64 bytes) longer than the value 
stored in the PSTL field in register 225. The PSTL or SSTL 
value is used by the address translation process to establish 
whether the entry designated by a segment index (SX) 
portion, as described below, of a primary or secondary 
virtual address respectfully falls within the primary or 
secondary ATST. 

TABLE 2 

Primary Segment Table Designation - Register 225 



X 


PSTO 




PSTL 



bits: 0 1 20 25 31 
where; **X" denotes a control bit. 



As noted above, the address translation process utilizes 
segments and pages. Generally, unauthorized access to the 
pages is limited by the use of protection keys, as described 
above. For the following discussion, it is assumed that the 
program producing the virtual address to be translated is 
authorized to access the resultant page frame, i.e.. the key in 
the PSW matches the key associated with the accessed page 
frame. 

Within main memory, each segment is a block of con- 
tiguous virtual addresses that spans 1 Mbyte and begins at a 
1 Mbyte boundary. A virtual page is a block of sequential 
virtual addresses that spans 4 kbytes and begins at a 4 kbyte 
boundary. An incoming virtual address, specifically address 
405, is divided into three fields: bits 1-11 form segment 
index (SX) field 410, bits 12-19 form page index (PX) field 
415, and bits 20-31 form byte index (BX) field 420. Bit 0 in 
the virtual address is not used. ATST and ATFT are initially 
used to translate virtual to real addresses. As such, the 
contents of these tables reflect a current assignment of real 
storage within the main memory of the computer. As noted 
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above, real storage is assigned in units of a full page frame 
with ail the locations being assigned contiguously within a 
page frame. These page frames, as discussed above, are 
generally not contiguous in main memory, although corre- 
sponding virtual pages are contiguous in virtual address 
space. 

With this in mind, address translation and protection 
verification process 220 begins with application of virtual 
address 405 and token 440 thereto. First, an effective seg- 
ment table designation is first generated. Based upon 
whether the user is employing primary or secondary virtual 
addressing, the contents of register 225 or 230 are used in 
translation as symbolized by lines 235 and 236, to form an 
effective segment table designation, specifically designation 
240. The ATST origin (ATSTO) residing in designation 245 
points to the beginning of an appropriate ATST, e.g., ATST 
150. for the user program From virtual address 405, the bits 
in segment index (SX) field 410 are appropriately routed, as 
symbolized by line 425, along with the ATST origin field, as 
symbolized by line 255. to ADD process 260 which appro- 
priately combines these fields to generate a real (or absolute) 
address into ATST 150. Specifically, the thirty-one bit 
address of the desired segment table entry is obtained, in real 
(or absolute) storage, by appending twelve bits having zero 
value to the right of bits 1-19 of the effective segment table 
designation and adding the value of segment index 410 from 
the incoming virtual address with two rightmost and eigh- 
teen leftmost zeros appended thereto, i.e., the value of the 
segment index is multiplied by four. All thirty-one bits of the 
resulting address produced by ADD process 260 are used to 
address ATST 150. As part of the segment table lookup 
process, bits 1-7 of virtual address 405 (the six most 
significant bits in the ATST) are compared against the value 
of the segment table length that resides in effective segment 
table designation 250 to establish whether, as noted above, 
the addressed segment table entry lies within the ATST, here 
ATST 150. If the value in the segment table length field is 
less than the value in the corresponding bit positions of 
virtual address 405. a segment translation exception is 
recognized. 

Each entry in ATST 150, though simplified somewhat in 
FIG. 2, has the specific format shown in Table 3 below: 
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associated segment is a so-called **private segment". In this 
case, this segment table entry and the ATPT it designates 
may only be used in association with the ATST origin that 
designates this particular ATST, i.e., ATST 150. 

5 Alternatively, if the value of the common segment bit is one, 
then the segment is a so-called "common segment**. In this 
case, the segment table entry and the page it designates may 
continue to be used for translating addresses corresponding 
to the segment index even though an ATST other than table 
150 has been specified by the ATST origin in effective 
segment table designation 240. 

If no exceptions are recognized during ATST lookup, then 
the resulting entry is fetched from ATST 150. here shown as 
entry 265. This entry specifies, through the ATPT origin 
(ATFTO) field, the real (or absolute) address of the begin- 

15 ning of a specific ATPT and, through the ATPT length 
(ATFTL) field, the length of this page table. 

Once segment table entry 265 is obtained, this entry along 
with the page index in virtual address 405 are used to access 
ATPT 160 to obtain the page frame address corresponding to 

20 the virtual page address. In particular, segment table entry 
270 obtained from ATST 150 is routed, as symbolized by 
line 280, to one input of ADD process 285. The page index 
(PX) is routed, as symbolized by line 430, to another input 
of ADD process 285. This process generates a thirty-one bit 

25 real (or absolute) address for ATPT 160 by first appending 
six zeros to the right of ATPT origin 270 and appending two 
rightmost and twenty-one leftmost zeros to page index 415, 
i.e., the value of the page index is multiplied by four, and 
then adding the resultants together. All thirty-one bits of the 

30 address to the page table are used. As part of the page table 
lookup process, the four leftmost bits of page index field 415 
are compared against the bits in the AITT length field 275 
to establish whether the addressed page table entry lies 
within ATPT 160. If the value in ATPT length field 275 is 

35 less than the value in the four leftmost bits in page index 
field 415, then a page translation exception is recognized 
Each entry in ATPT 160, though simplified somewhat in 
HG. 2, has the specific format shown in Table 4 below: 

40 TABLE 4 

Address Translation Page Table Entry 



TABLE 3 
Address Translation Segment Table Entry 



0 


ATPT Origin 


I 


C 


ATPTL 



45 



50 



bits: 0 1 26 27 28 31 

where: I is an invalid bit; and 

C is a common segment bit. 



As shown above, the first bit in a ATST entry is set to a zero 
value. The next twenty-five bits (bits 1-25), with six zeros 55 
appended to the right, form the ATPT origin (ATPTO) for a 
specific ATPT. The ATPTO can be real or absolute. The 
invalid bit (I), bit 26, is set to a zero state to signify that the 
segment table entry is valid, i.e., meaningful, and available 
for use during subsequent address translation. If this bit is 60 
reset to one. this signifies that the associated segment table 
entry is not meaningful and cannot be used during address 
translation. As such, if this entry is accessed therefor, a 
segment translation exception will then be recognized. The 
common segment bit, bit 27. identifies the manner through 65 
which the segment table entry can be used. Specifically, if 
the value of the common segment bit is zero, then the 



PFRA 



irrelevant 



bits: 0 1 



20 



31 



where: PRFA is a page frame real address, referred 
to herein as simply a page frame 
address; 
I is an invalid bit; and 
P is a page protection bit. 



As shown above, the first bit in a page table entry is set 
to a zero value. The next nineteen bits (bits 1-19) provide 
the leftmost twenty bits of the page frame address 295. 
When these bits are concatenated to the left of the twelve bit 
address in byte index field 420, a thirty-one bit real address 
results. The invalid bit (I), bit 21, specifies whether that page 
table entry is valid, i.e., meaningful, and available for use 
during translation of the current virtual address. When this 
bit is zero valued, this page table entry is meaningful and can 
be used during translation; omerwise, if this bit is a one, this 
page table entry is not meaningful and cannot be used during 
translation. The page protection bit (P) 300, bit 22, specifies 
whether stores (write operations) can be made into the 
corresponding page frame in main memory but does not 
affect fetch accesses from this page. If this bit is zero valued 
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then address translation and protection verification control- Each entry in PVST 175, though simplified somewhat in 

ler 450 detects this condition via line 310 and permits data FIG. 2. has the specific format shown in Table 5 below: 
storage into this page; otherwise, if this bit is one. stores are 

disallowed unless the user program requesting the transla- TABLE 5 

tion provides a token to override the page protection. The 5 Protection Verification Segment Table Entry 

use of tokens is described below. Bit positions 0, 20. and 23 

of each page table entry must contain zeros; else, a trans- | 1 1 . 

lation exception is recognized as part of the execution of an pvpt Origin unused I 

instruction that uses this page table entry for translation. Bit bits: o 23 30 31 

positions 24-31 of a page table entry are irrelevant to the 10 

present invention. where: I is an invalid bit 



If no exceptions are recognized during ATPT lookup, then 

the entry fetched from the ATPT. here shown as entry 290. ^.^^J^i^ first twenty-three bits (bits 0-22) 

. « « ~ n - , . . _ A _ contain PVFTO 365. a real address of an origin of a 

provides page frame address 295 for virtual address 405. i5 nrrtW ; ftn ' „ a<M , . , mvvr , u-iTk-^ 

xtru » * a iU u ^ * j . . protection verification page table (PVFT). The last bit (bit 

When concatenated with byte index 420 the combination 31)> a vaM ty bit (y) 3^ set to a 2Cf0 ^ to s • ~ ^ 

forms real address 315. Line 435 routes byte index 325 from me PV sr is valid, i.e. meaningful, and available for use 

virtual address 405. Line 305 routes page frame address 320 during subsequent protection verification. If this bit is reset 

from page table entry 290. to one. this signifies that the associated PVST entry is not 

If the page frame is not page protected, address translation 20 meaningful and cannot be used during protection verifica- 

and protection verification controller 450 permits real tion. As such, if thus entry is accessed therefor, a protection 

address 315 to be used, via lines 400 and 460, to access a verification exception will then be recognized. Action taken 

byte location within the main memory for either fetch or bv Ae P roce $ sor response to a protection verification 

store operations. However, if the page frame is protected, m exc eP tion ** discussed below. 

then the real address can only be used to access the page 25 ff *> «cq*OM aw ^re^cognized during PVCT lookup, then 

frame for fetch operations. Using our inventive token con- T 7 ^ t T ^ 

tmiun n rr*^™ tw ,u nJftlw 0 etrtrA rtrtAMH * rt „ ™ *™ 360 ' specifies, through the PVPT address, the real address of 

troUed page prelection techiuque, a store operation, or any ^ of a s ^ edfic pvpr 

operations mat alter tne contents 01 a page rrame, can De Q ^ pvyr 3fi0 

is obtained, this entry, alone with 

r^oimediffceuserprogram^ 30 the page index in virtual address 405, is used to access PVPT 

holds an authorized token provided by using a special 185 t0 obtain ^ token correspondillg t0 me virtual page 

instruction as discussed above. address ^ parti cular. PVST entry 360 obtained from PVST 

Typically, as discussed above, the operating system pro- 175 is routed, as symbolized by line 375, to one input of 

duces a token whenever a program requests protection of a ADD process 380. The page index (FX) is routed, as 

page frame. The program stores the token in a register for 35 symbolized by line 430 to another input of ADD process 

future use, i.e., for retrieval when using one of the special 380. The ADD process appends nine zero-valued bits to the 

instructions. Moreover, other programs can be authorized to right of PVST entry 360 and appends one rightmost and 

store to the protected page if they are provided with the twenty-two leftmost zero-valued bits to the page index 

location of the register storing the token. value > ^ &e value of me P a 8 e index is multiplied by two. 

Once the virtual to real address translation is complete, 40 ^ resultant ~ ^ w f^ SS 

f „ . . *u * 1 ijij . process generates a thirty-one bit real address to PVFT 185 

the following process determines if the token provided by ^ g £ 0 

the program matches a token associated with a protected ^ m pvpT m ^ a ^ ^ ^ token 

page frame. If the tokens match, the processor permits haying a spedfic foimat shown m Table 6 bclow: 

alteration of the page frame; otherwise, execution of the user 45 

program is halted. TABLE 6 

Register 330 contains information that serves as the ^ — — — — 

protection verification segment table pointer (PVST pointer) Protection Verification Page Tabic Entry 

for facilitating determination of a token associated with the 
presently translated page address. The PVST pointer serves 50 
as a designator of memory space 340 containing the pro- 
tection verification segment table origin (PVSTO). PVSTO — — 
345 marks the beginning of an appropriate protection veri- ^ TOrw , , ^ . „ , 
fication segment rtfc (PVST). ITS, far the user. „ t ^1™°°^* 512 PVT 7. entry con- 

From virtfal address 405, the bits in segment index (SX) 55 T™? «j£ ^T^^ ?^™'^™ 

£ i j J4 a . «. t A . 6 . . . has its protection bit set A two byte length permits 65,536 

field 410 are a^pr^dy routed, as symbohzed by kne uni ^ okens address s * t0 b * t0 ^ 

425. along with the PVSTO, as symbolized by line 350, to ope ? ating system l or assignment Additionally, by having 

ADD process 355 which appropriately combines these fields 512 PVFr entries corresponding to tokens for 512 page 

to generate a real address into PVST 175. Specifically, the ^ ^ men e ight FVPTs can be stored into a single page 

thirty-one bit address of the desired PVST entry is obtained, frame of real memory space. 

in real storage, by appending twelve zeros to the right of bits Subsequently, address translation and protection verifica- 

1-19 of the effective PVST designation and adding the value tion controller 450 compares retrieved token 390, via line 

of segment index 410 from the incoming virtual address 395. with token 440 supplied, along path 445, by the user 

with two rightmost and eighteen leftmost zeros appended 65 program requesting access to me protected page frame. If the 

thereto. All thirty-one bits of the resulting address produced tokens match, the controller permits access to the page frame 

by ADD process 355 to PVST 175 are used. by producing real address 315 on path 460. Consequently, 



TOKEN 



bits: 0 15 
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the program can alter the data at real address 315. However, control is returned to the program to continue user program 

if the tokens do not match or the program requesting to store execution symbolized by dashed line 535. However, if the 

to the page frame does not have a token, address translation tokens do not match, the hardware issues, at step 575, a 

and protection verification controller 450 produces a pro- protection verification exception. In response to the protec- 

tection verification exception on path 455. As such, the 5 tion verification exception, the operating system terminates, 

operating system will terminate the program for making the at step 580, user program 470. 

unauthorized storage request. Additionally, if for any reason As a result of the foregoing token controlled page pro- 

during the address translation and token verification process tection technique, our invention provides a memory space 

a protection verification exception is generated, the operat- protection technique which allows a program that has pre- 

ing system will terminate the program which caused the 10 viously requested page protection to both read and write 

exception. information to its protected page without opening the page 

FIG. 3 is a flow chart depicting the various process steps to inadvertent overlay. Our memory protection technique is 

(collectively referred to as Token Controlled Page Protection fully compatible with present virtual memory storage sys- 

Routine 465) which occur within user program 470, oper- terns and their present protection techniques, 

ating system 475, and hardware 480 (including the processor 15 The address translation and protection verification pro- 

and memory access hardware) to facilitate our page protec- cess described above assumes that such a process is utilized 

tion technique (depicted as token controlled page protection for each and every access to memory. In practice, such 

routine 465). To simplify FIG. 3. routine 465 does not depict utilization tends to be relatively slow and adds significant 

the process for building the address translation segment and overhead to memory access and instruction execution times, 

page tables. Such a process is old in the art; therefore, those 20 Hence, if the full address translation and protection verifi- 

skilled in the art will readily be able to implement such a cation process were to be performed for every virtual 

process. address, then these times would be slowed considerably 

Beginning at step 485, routine 465 depicts the user which, in turn, would substantially decrease the throughput 

program requesting a page of storage. Additionally, at step of the computer. Therefore, in an attempt to substantially 

490, user program 470 requests page protection for that page 25 eliminate the need to perform the entire address translation 

of storage. In response to the request, operating system 475 and protection verification process for every virtual address, 

queries, at step 45*5, whether a PVST is built If not, the a translation lookaside buffer (TLB) can be used. TLBs are 

operating system builds the PVST at step 500. If the PVST widely used and well known in the art of address translation 

is not built, neither is the PVFT. Therefore, once the PVST processes. Generally, these buffers, in hardware, store 

is built through step 500, the operating system builds, at step 30 recently used virtual page addressed along with their coire- 

510, the PVFT. Alternatively, if the PVST is found, at step sponding page frame addresses. Once a virtual page address 

495, to exist, the routine queries, at step 505, whether the has been fully translated, this virtual address along with its 

PVFT exists. If the PVST does not exist, the operating corresponding physical page frame address are stored in a 

system builds the PVFT at step 510. However, if the PVFT common entry in the TLB for subsequent use. Those skilled 

exists, the routine proceeds to step 515. 35 in the art will realize that such a TLB entry can be expanded 

At step 515, the operating system generates a unique to also include a token corresponding to the translated 

2-byte token for the present request by this user program. virtual address. 

The operating system stores, at step 520, the token as an Consequently, when such a TLB is in use, then prior to 

entry in the PVFT, And at step 525, the operating system performing a full address translation, the address translation 

returns the token to program 470. 40 process determines whether an incoming virtual page 

At step 530, the user program stores the token in a register address resides within the TLB. If so, the corresponding 

location and then proceeds with a normal program execution page frame address and associated token (if the page is 

(symbolized by dashed line 535). Subsequently, when the protected) is accessed therefrom and then used to form a real 

user program issues an instruction to modify the information memory address which, in turn, is used to access main 

currently stored in the previously protected page, the pro- 45 memory. If not, full address translation and protection 

cesser must utilize the PVST and PVFT. To facilitate modi- verification occurs, and a new entry in the TLB is created for 

fying the protected page, the user program issues a special the latest virtual page address, its corresponding page frame 

instruction, at step 540. The special instruction to update a address and a token. Hence, only those virtual addresses that 

protected page retrieves the token from the register and have virtual page addresses which are not stored in the TLB 

provides that token to hardware 480. Along with the token, 50 are fully translated. Advantageously, this, in turn, drastically 

the user program supplies a virtual address which will be reduces the number of full address translations and protec- 

operated upon by the instruction. The microcode within the tion verifications that must occur during program execution, 

hardware performs address translation and protection veri- FIG. 4 diagrammatically shows user program 470 with an 

fication. At step 550, the hardware translates the virtual page instruction having an OP CODE and parameters (r) being 

address to a real page address (page frame) in the manner 55 executed by processor 100. As a first example, the OP 

previously described herein. At step 555, the routine queries CODE may simply represent a write instruction requesting 

whether that page frame is protected, i.e., is the protection that data be written into a previously created unprotected 

bit set If no protection is evident, the hardware permits, at storage area having virtual address VA. In this case, param- 

step 570, the storage location to be updated. However, if the eters (r) contain virtual address VA. Upon execution of the 

protection bit is set, the routine proceeds to step 560. At step 60 write instruction, address translation apparatus 600 trans- 

560. the token provided by the user program is compared to lates virtual address VA into a real address RA, determines 

a token assigned to the protected page frame. As previously that the page is unprotected and permits alteration of the data 

discussed, the token assigned to the protected page frame is in main memory 110 at real address RA. As a second ' 

found by using the PVST and the PVPT. If, at step 565, the example, if the OP CODE in user program 470 is a request 

tokens are determined to match, the hardware permits, at 65 for page protection of a storage area specified by virtual 

step 570. the user program to access and update the memory address VA, which is one of the parameters (r), protection 

location indicated by the virtual address. Afterward, process apparatus 601 responds by transmitting protection data to 
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address translation apparatus 600 to establish a protected FIG. 6 shows processor 100 of virtual storage computer 

view of the storage area. system 699 executing user program 470 to obtain token 

In accordance with the previous discussion, a page pro- protection for an area of storage. System 699 includes virtual 

tection request may simply be a conventional request that address generator 602, token table 603, effective ATSTO 

data in the protected area be protected from alteration. As 5 register 640 and virtual address register 605. System 699 

such, the protected view established by protection apparatus ^ includes conventional address translation apparatus 600 

601 would be activated only in response to operations that having address translation segment table 150 pointing at 

would alter data in the protected area. Of course, it is address ^Mon page ^ 160) ^ address 

understood that the present invention conceives fear a pro- t ^ m ad(Jr teble 

tection request may include conventional requests that the tctk n A^^\^ i * ^ i L 

data be protected from other operations such as e.g. fetch, 10 660 * Tables *° . f ™ «™dae the virtual addresses in 

read or execute user space US into corresponding real addresses of real 

For the embodiment shown in FIGS. 1-3, setting protec- stora 8 e - Tables 650 and 660 translate the virtual addresses in 

tion bits (P) 300 to a page protected state, e.g. a binary 1, svstem Ss mt0 real addresses of real storage areas, 

establishes page protected views with respect to data alter- ne storage of spaces SS and US, and the real storage 

ations only. Consequently, a conventional (non-token) 15 °f corresponding page frames are collectively graphically 

request to read the data at virtual address 405 will cause illustrated in FIG. 5. 

ATST 150, ATPT 160 and control 450 to activate an unpro- Specifically, FIG. 6 illustrates virtual storage computer 

tected view of the storage area so that the data may be read. system 699 executing user program 470 to provide a token 

However, a conventional (non-token) request to write data to protected virtual storage area A having N pages of data. The 

address 405 will cause ATST 150, ATPT 160 and control 450 20 process steps involved in obtaining this token protection are 

to activate a protected view of the storage area by generating illustrated in FIG. 7. For ease of understanding, the reader 

a protection verification exception on path 455. should simultaneously refer to FIGS. 6 and 7 throughout the 

A token controlled protection request by user program following discussion. The CREATE A/N instruction of pro- 

470 (shown in FIG. 4), establishes an alternate view of the gram 470 (see FIG. 6) requests that N pages of virtual 

protected area. This alternate view, when activated, will 25 storage be created in user space US of FIG. 5. FIG. 7 depicts 

permit user program 470 to access the protected area to alter this step via REQUEST step 701. Processor 100 responds by 

the data therein. In response to the token controlled protec- activating virtual address generator 602 of operating system 

tion request, protection apparatus 601 transmits token con- 475. Generator 602, via CREATE PAGES VA1/N/US step 

trolled protection data to address translation apparatus 600 702, creates a virtual storage area A of N contiguous virtual 

to establish the protected and access views for the area. 30 pages having virtual address VA1 in user space US. FIG. 5 

Additionally, protection apparatus 601 passes user token UT illustrates the N contiguous virtual pages as PAGE 1. PAGE 

to user program 407 as a corresponding system token ST is 2, . . . PAGE N in user space US. Processor 100 next returns 

passed to translation apparatus 600 for use in activating the the page location (VA1/N/US) over path 607 to user program 

access view when it is necessary to alter the contents of the 470, which stores the page location (VA1/N/US) via STORE 

protected area. 35 step 703. 

In the embodiment of FIGS. 1-3 (with parenthetical User program 470 next requests, via TOKEN PROTECT 

references made to the steps shown in FIG. 5), operating VA1/N/US instruction of FIG. 6 and REQUEST step 704 of 

system 475 establishes the protected view by setting pro- FIG. 7, that token protection be provided for virtual storage 

tection bit (P) 300 in ATPT 160 to a one, as described above. area A. Operating system 475 responds by accessing or 

Operating system 475 also establishes the access view by 40 building, if necessary, token table 603 in steps 705 and 706. 

storing system token 385 (step 520) in PVFT 185 and Additionally, virtual address generator 602 constructs, via 

sending the matching user token 440 (step 525) to user CREATE step 707, an alternate virtual storage area A' 

program 470. During execution of a token related having N+l contiguous pages at virtual address VA2 in 

instruction, user program 470 provides virtual address 405 system space SS. FIG. 5 illustrates the N+l contiguous 

and user token 440 to activate the access view of the 45 virtual pages of alternate area A' as PAGE 1', PAGE 2', . . . 

protected area via tables 150, 160, 175 and 185 and control PAGE N 1 and isolate PAGE N*+l in system space SS. 

450. Activating the access view causes virtual address 405 Operating system 475 also relates the data of virtual 

to be translated into real address 315, via tables 150 and 160, storage area A to that of virtual storage area A 1 and real 

and into system token 385, via tables 175 and 185. Control storage via step 708. In that regard, processor 100 performs 

450 provides access to the protected area by outputting real 50 process step 708 by inputting, via path 610, appropriate page 

address 315 on path 460 after successfully comparing user frame addresses (PFRAs) 295 into ATPTs 160 and 660. 

token 440 with system token 385. Specifically, processor 100 loads the same PFRA 295 in 

The embodiment of FIGS. 1-3 accomplishes token con- entry (1) in ATPT 160 and entry (1*) in ATPT 660. ATPT 

trolled protection with protection verification tables 175 and entries (2) and (2') are also loaded with a common PFRA 

185, which collectively translate a virtual address into a 55 295. Finally, processor 100 loads entries (N) and (N) with 

corresponding system token. These tables along with their a common PFRA 295. Consequently, corresponding ATPT 

peripheral elements and control 450 are preferably imple- entries related to user space US and system space SS will 

mented using hardware logic devices such as those used to translate to the same pages in real storage, 

implement the conventional address translation logic For example, with reference to FIG. 5, PAGE 1 of user 

devices that include tables 150 and 160. Therefore, imple- 60 space US and PAGE 1' of system space SS both correspond 

menting token controlled protection in existing computer to PAGE 1" of real storage. Likewise, PAGE 2 of user space 

systems in accordance with the embodiment in FIGS. 1-3 US and PAGE 2* of system space SS both correspond to 

typically involves retrofitting existing computer systems PAGE 2" of real storage, and so on. It is noted that isolate 

with new hardware units. To avoid the retrofitting expenses, PAGE N*+l in system space SS has no equivalent page in 

which can be significant, users of existing systems may 65 user space US or real storage. To illustrate this condition in 

employ the software implementation of our present FIG. 6, PFRA 295 in entry N4-1 of ATPT 660 consists of a 

invention, which is illustrated in FIGS. 5-9. dashed line and validity field 370 has an I to indicate that 
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PFRA 295 for that entry is invalid The purpose of isolate control 646 receives inputs of page frame addresses 295 and 

PAGE K+l will become evident below. page protection bits (P) 300 of ATPTs 160 and 660 respec- 

Operating system 475 next selects, via SELECT TOKEN tively. An OP CODE input provides instruction information 

step 709, an available system token ST from token table 603. over path 658 to protection verification control 646. which, 

Operating system 475 makes a copy of the selected system 5 in turn, provides a PFRA input to register 655. Processor 100 

token ST and passes that copy to user program 470 (as provides virtual addresses VA over path 656 to virtual 

symbolized by dashed path 606 in FIG. 6) as a user token UT address register 605 which, in turn, communicates segment 

for storage in STORE USER TOKEN TJT step 710. FIG. 6 index SX to ADD process 260, page index PX to ADD 

illustratively shows processor 100 selecting the available process 285 and byte index BX to real address register 655. 

system token ST from token table entry 615. Operating 10 To execute a conventional read operation of N pages of a 

system 475 then initializes, via INITIALIZE step 711, the protected area, such as the protected area having virtual 

data fields in token table entry 615 over path 610. address VA1 in user space US, processor 100 executes 

Specifically, processor 100 loads the following data into READ VA1/US/N instruction of user program 470. Proces- 

token table entry 615: VA1 (the user space virtual address of sor 100 obtains access to the corresponding real address RA 

area A), N (the number of pages in area A), US (the user's 15 by loading virtual address VA1 in register 605 and user 

virtual space in which area A is located). VA2 (the system space US in register 640. ADD process 260 responds by 

space virtual address of area AO and SS (the system's virtual pointing to segment table entry 270 in segment table ATST 

space in which area A' is located). 150 related to user space US. The ATPTO of entry 270 in 

Finally, operating system 475 transmits, via PROTECT table 150 and page index PX of register 605 cause ADD 

steps 712 and 713, protection bits (P) 300 to the entries of 20 process 285 to point at an entry of ATPT 160. PFRA 295 and 

ATPTs 160 and 660. As can be seen in FIG. 6. each of the protection bit (1) 300 in this entry are sent to control 646. 

entries (1>-(N) of ATPT 160 has its protection bit (P) 300 set The OP CODE input sends the READ instruction over path 

to 1 to indicate that each corresponding page is protected. 658 to control 646 which, in turn, determines if the READ 

Further, the protection bits (P) 300 for each of the entries instruction is protected by protection bit (1) 300. Since the 

(l')-(N 1 ) °f 660 are set to 0, indicating that each 25 area is protected only with respect to operations that alter 

corresponding page is not protected. Entry (N*+l) of ATPT data, control 646 permits operating system 475 to execute 

660 is set to 1, indicating that its corresponding isolate page the READ instruction. Control 646 loads PFRA 295 in 

is protected. Processor 100 sets protection bits (P) 300 in register 655 which, in turn, outputs real address RA1 on path 

successive steps as the outputs of ATSTO 640 and virtual 460. The process is repeated for each of the N pages of 

address register 605 selects the corresponding entries in 30 virtual storage as processor 100 loads N successive virtual 

ATPTs 160 and 660. Specifically, token table 603 loads addresses VA for the N contiguous virtual pages. Since the 

virtual address register 605 with virtual addresses VA1 and page protection bits (P) 300 for each of the entries (1)-(N) 

VA2 over path 618. Addresses VA1 and VA2 correspond to is a one, control 646 permits the data in each page to be read 

the respective first page of each area A and A'. Over path by loading the appropriate PFRA 295 in register 655. 

617, processor 100 loads ATSTO register 640 with data 35 The second instruction in user program 470 of FIG. 8 

identifying user space US and system space SS. Over path illustrates a conventional write instruction to virtual address 

619, processor 100 increments page index PX of virtual VA1. When processor 100 executes WRITE VA1/US 

address register 605 through the N and N+l pages of areas instruction, the processor loads virtual address VA1 into 

A and A\ respectively As ADD process 285 points in N register 605 and user space US in ATSTO register 640. In 

successive steps to entries (1)-(N) of ATFT 160 and then in 40 response, ADD process 260 points to segment table entry 

N+l successive steps to entries (l'HN'+l) of ATPT 660, 270 in segment table ATST 150 for user space US. The 

processor 100 sets the corresponding protection bits (P) 300 ATPTO data of entry 270 in table 150 and page index PX of 

to the values shown in FIG. 6. register 605 cause ADD process 285 to point to an associated 

As described below in detail, the setting of protection bits entry of ATPT 160. ATPT 160 outputs PFRA 295 and 
(P) 300 to a 1 in ATPT 160 establishes a protected view of 45 protection bit (1) 300 in this particular entry to control 646. 
the data in the N pages in real storage. Likewise, the setting The OP CODE input sends the WRITE instruction over path 
of protection bits (P) 300 to a zero in ATFT 660 establishes 658 to control 646, which, in turn, determines that the page 
an access view of the protected data in the N pages of real is protected with respect to the requested WRITE ins true- 
storage. The setting of protection bit (P) 300 to a one for the tion. Since the area is protected with respect to operations 
isolate page entry (N*+l) in ATFT 660 acts to isolate the 50 that alter data, control 646 disallows the WRITE instruction 
unprotected pages from other unprotected pages by at least by activating exception generator 647 to send a program 
one protected page. This prevents programs that obtain a exception to processor 100 over path 455. 
valid update pointer from altering data beyond the range, As explained above, to write data to a protected area, 
i.e., the end of the Nth (last) page (e.g., via a move character system 699 must obtain an access view of the protected area, 
long (MVCL) instruction). 55 Now, simultaneously referring to FIGS. 5, 8 and 9 (with 

FIG. 8 illustrates processor 100 of virtual storage com- FIG. 9 showing a sequence of steps performed by our 

puter system 699 executing a series of read and write inventive embodiment depicted in FIG. 8). assume that user 

instructions in user program 470. In addition to the elements program 470 desires to write data to a virtual storage 

described with respect to FIG. 6, system 699 also includes location in user space US using a user's virtual address VA3, 

token verification control 645, protection verification control 60 i.e. a point located in PAGE 2 of protected area A as seen in 

646, exception generator 647 and real address output reg- FIG. 5. Before executing the WRITE instruction, user pro- 

ister 655 as previously depicted in FIG. 8. Token verification gram first uses the previously obtained user token UT 

control 645 receives inputs from the data fields of entry 615 associated with the protected area A to obtain a pointer, 

in token table 603. Over path 648, processor 100 provides a Specifically, POINTER=UT/VA3/US instruction requests, 

protected virtual address input to token verification control 65 via step 901, that a pointer to the access view be returned to 

645 which, in turn, provides an accessible virtual address program 470. In RETRIEVE step 902. operating system 475 

input to processor 100 over path 649. Protection verification enters token table 603 and scans system tokens ST to find a 
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match for user token UT, thereby locatuig the proper table More specifically, after operating system 475 increments 

entry 615. Token verification control 645 receives the data (see INCREMENT step 925) the virtual address in register 

contained in table entry 615 along with user virtual address 695 to address VA7, Le. the address of isolate PAGE NM-1, 

VA3 via path 648. As seen in FIG. 5, user virtual address ADD process 285 points to entry (N4-1) in ATPT 660 of 

VA3 is assumed to correspond to an internal point X in 5 FIG. 8. In P=l? step 930, protection verification control 646 

PAGE 2 of area A. wiU fincl P a 8 e protection bit (P) 300 set to a 1. indicating that 

In VERIFY step 903. token verification control 645 of me ^ k protected. Since the OP CODE is a write 

operating system 475 first verifies that point X resides instruction, protection verification control 646 sends an 

somewhere in the N virtual pages of area A and determines £«£ tion »o raception generator 647 and EXCEP- 

a value of virmaladoressV4coiTesponding to user virtual 10 2f ^ ^ P?™^™™ .„ . . 

address VA3. Using the page size, the numb«N of protected , f^dui the ES^390 w^readdy appreciate that 

pages and the value in table entry 615 for virtual address token f ? tecb ° n m accortoc* with this embodmient of the 

VA1. token verification control 645 determines virtual P^f ^fT 7, * EftSE** ^ 

address VA9 for the point located at the end of area A (see s Vf! mo f ** PROTECT service pro- 

HG. 5). Control 645 then verifies that user virtual address is vi ^ d . * ** ^/ESA operattng systen^ Of course, those 

VA3. supplied by program 470. lies within area A. i.e.. J?^^ ^ also appreciate that both embodiments of 

address VA3 is greater than address VA1. taken from table m ™ tX0D *** te simultaneously to the same 

entry 615. and less than address VA9. calculated by control COm 5U.5 Sy f, . . Jt 

645. If user address VA31ies outside area A, controfW via AdditionaUy, unprotected storage area A in system space 

decision step 904 and EXCEPTION step 905. sends an 20 ?? may be placed in other spaces including user space US. 

exception signal over path 659 to exception generator 647. However to reduce the chances of having an accidental 

If control 645 verifies that user address VA3 lies in area overlay of its unprotectedpages, area A 1 is preferably looted 

A. control 645 calculates its corresponding pointer address J? , TV* SU ° h ? T?J S ' 

VA4 in system space SS and passes it to user program 470 me ."J^E* «°Pkmentotion, area A. the protected area, 

(see path 660 in FIG. 8) for insertion, via INSERT 25 ^ to ^^^ , 'T" ,,tal '^ 1,1B 

POINTER step 906, in the WRITE instruction as a pointer addres , s f ould . be * ^J ddress s P ace number or u a 

to the access view. Control 645 calculates pointer address sp * ce t0keD fw 8 ^.space Address space storage can be 

VA4 by calculating the distance between addresses VA1 and h f omm ^ n 01 P™* of kev usin S 

VA3. and then adding that distance to the value of address P'^™:,^ 8 ™* "J"*? m a COmm ?° ***** 

VA2 as taken from table entry 615. 30 *5 ^ ^™ 

Next through WRITE VA4/SS step 907. user program 470 VA4 ' be *^, SS t * BB (ALBT) 

requests that me access view be activated so that dam can be aeCeSSa 7 t0 add T eSS * e CADS - Ms °< ^ead cf trannuttuig 

written to the real storage starting at real address RA2 of a f cs £ oa Slg °l° Ver P ath 659 w ^ n f "f*^ 

PAGE 2" which corresponds to pointer virtual address VA4, f toke " .^Ti. fou ° d °' user T*. address( * 

in system space SS. and user virtual address VA3, in user 35 18 outslde «■ A, total verification control 

space US. Address translation apparatus 600 responds to this «f ^^£T*™ ^^'Tf 

write request by accessing pages in real storage one page at of ^ N+1 Whldl ' WheD wlU WSUlt m 

a time. Address translation apparatus 600 first performs an exception. 

TRANSLATE VA4/SS-to-RA2 step 908. Specifically, pro- . ^ °^J^T ^^f^ ° f 

cessor 100 first loads pointer address VA4 in register 605. 40 * ave ^ jUustrated and described herein many moduica- 

over path 656, and system space SS in ATSTO renter 640, ^ 0ns f and ™" °f™ X ? *°f e ^d m the art It is, 

overpam617.Thiscaus«ADD F ocess260topointtotable t0 * ^jf™^ *f daum> ™ 

entry 270 of ATST 650, in turn, causing ADD process 285 ^/ u ^ modlfic ^ons and changes as fall 

to point to entry (2') in ATFT 660. Protection verification ^ * e s P mt of to inventlon - 

control 646 then reads PFRA 295, page protection bit (P) 45 - e A C T m * , ^ * , . ' 

300andmeOPCODEformewriteM ^ }: ^^ rtual borage computer system having token con- 

909,protectionverificationcontrol646verifiesthatthepage ^age protection comprising: 

is unprotected. If P equals one, EXCEPTION step 905 a Processor; 

performs a program exception. If P equals zero, operating a reai storage means for providing a real storage area with 

system 475 writes to PAGE 2" starting at address RA2 (see 50 a real address; 

ALTER step 910). Next, in INCREMENT step 911, proces- a virtual storage means for providing a first virtual storage 
sor 100 increments the virtual address in register 605 to area with a first virtual address; 
VA5, the top of the next page. TRANSLATE step 912 a user program means for execution by said data 
translates address VA5 into real address RA3.P=1? step913 • processor, said user programmeans having a protection 
checks for page protection; ALTER step 914 writes data to 55 request means for requesting that said token controlled 
real address RA3, and so forth. storage protection be provided for said real storage area 
This process of accessing pages of real storage one page via said first virtual address and that a corresponding 
at a time continues until either all of the data has been user token be returned by said processor, a store means 
written to storage or isolate PAGE N+l has been reached in for storing said user token corresponding to said first 
ATPT 660, whichever occurs first In other words, when the 60 virtual address, and access request means far request- 
accessible storage is greater than the total data to be written, ing access to said real storage area and wherein said 
operating system 475 simply writes each page of data and access request means includes a token-request means 
then executes the next instruction in user program 470. for requesting access to said real storage area via a 
However, when the accessible storage is less than the total token-accessible view of said real storage area; 
data to be written, the isolate page entry (N+l) in ATST 660 65 an address translation means responsive to said access 
will eventually be encountered causing a program exception request means for translating a virtual address into a 
to be generated. corresponding real address; and 
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token protect means, responsive to said protection request 
means, for generating said user token and a correspond- 
ing system token, and area protection means for estab- 
lishing a protected view and said token-accessible view 
via said address translation means. 5 

2. The system of claim 1 wherein said token-access 
request means includes means for providing a user virtual 
address and said user token. 

3. The system of claim 2 further including exception 
means for generating a program exception when said user 
program activates said protected view. 

4. The system of claim 3 wherein said address translation 
means includes means for translating said user virtual 
address into a corresponding real address and outputting said 
corresponding real address when said user program activates 
said token-accessible view. 15 

5. The system of claim 4 further including means for 
activating said token-accessible view in response to said 
access request means providing said user virtual address and 
said user token. 

6. A virtual storage computer system having token con- 20 
trolled storage protection comprising: 

a data processor; 

a real storage means for providing a real storage area with 
a real address; 

a virtual storage means for providing a first virtual storage 25 
area with a first virtual address; 

a user program means for execution by said data 
processor, said user program means having a protection 
request means for requesting that said token controlled 3Q 
storage protection be provided for said real storage area 
via said first virtual address and that a corresponding 
user token be returned by said processor, a store means 
for storing said user token corresponding to said first 
virtual address, and access request means for request- 35 
ing access to said real storage area and wherein said 
access request means includes a token-access request 
means for providing a user virtual address and said user 
token for requesting access to said real storage area via 
a token-accessible view of said real storage area; 

40 

an address translation means responsive to said access 
request means for translating a virtual address into a 
corresponding real address; and 

token protect means, responsive to said protection request 
means, for generating said user token and a correspond- 45 
ing system token, and area protection means for estab- 
lishing a protected view and said token-accessible view 
via said address translation means. 

7. The system of claim 6 wherein said address translation 
means includes means for translating said user virtual 50 
address into said system token. 

8. The system of claim 7 wherein said address translation 
means includes a token verification control means for com- 
paring said user token to said system token, for providing 
said real address when said user and. system tokens 55 
correspond, and for providing a program exception when 
said user and system tokens do not correspond. 

9. A virtual storage computer system having token con- 
trolled storage protection comprising: 

a data processor; go 
a real storage means for providing a real storage area with 

a real address; 
a virtual storage means for providing a first virtual storage 
area with a first virtual address and a second virtual 
storage area with a second virtual address, said second 65 
virtual storage area corresponding to said first virtual 
storage area and said real storage area; 



a user program means for execution by said data 
processor, said user program means having a protection 
request means for requesting that said token controlled 
storage protection be provided for said real storage area 
via said first virtual address and said second virtual 
address, and that a corresponding user token be 
returned by said processor, a store means for storing 
said user token corresponding to said first virtual 
address, and access request means for requesting access 
to said real storage area; 

an address translation means responsive to said access 
request means for translating a virtual address into a 
corresponding real address; and 

token protect means, responsive to said protection request 
means, for generating said user token and a correspond- 
ing system token, and area protection means for estab- 
lishing a protected view and a token-accessible view of 
said real storage area via said address translation 
means. 

10. The system of claim 9 wherein said area protection 
means establishes said protected view of said real storage 
area with respect to said first virtual address, and establishes 
said token-accessible view of said real storage area with 
respect to said second virtual address. 

11. The system of claim 10 further including a token table 
means for storing said system token, said first virtual address 
and said second virtual address. 

12. The system of claim 11 wherein said access request 
means includes a pointer request means for using said user 
token to locate a corresponding system token in said token 
table means and to retrieve a pointer virtual address corre- 
sponding to a user virtual address provided with said user 
token by said access request means. 

13. The system of claim 12 wherein said token table 
means includes a token verification control means for gen- 
erating said pointer virtual address and passing it to said 
access request means if said user virtual address is calcu- 
lated to be in said first virtual storage area, and for requesting 
an exception if said user virtual address is not in said first 
virtual storage area. 

14. The system of claim 13 wherein said access request 
means requests access to said real storage via said token- 
accessible view by providing said pointer virtual address. 

15. The system of claim 14 further including an isolating 
storage area contiguous with said second virtual storage 
area, and wherein said token protect means establishes a 
protected view of said real storage area with respect to the 
virtual address of said isolating storage area. 

16. A method of token controlled storage protection in a 
virtual storage computer system having a real storage and a 
virtual storage, said method comprising: 

creating, in said real storage, a real storage area with a real 
address; 

creating, in said virtual storage, a first virtual storage area 
with a first virtual address and corresponding to said 
real storage area; 

establishing a protected view and a token-accessible view 
from a user program to said real storage area via an 
address translation means, including acquiring a user 
token and a system token corresponding to said first 
virtual storage area, and storing said user token in said 
user program; 

requesting access to said real storage area by providing 
said user token and a user virtual address via said user 
program; and 

comparing said user token with said system token and, if 
said user and system tokens correspond, activating said 



11/19/2003, EAST version: 1.4.1 



5,628,023 

29 30 

token-accessible view and outputting said real address, 20. The method of claim 19 wherein said establishing said 

and if said user and system tokens do not correspond, token-accessible view includes relating said first and second 

activating said protected view and outputting a program virtual addresses and said system token in a token table, 

exception. 21. The method of claim 20 wherein said requesting 

17. The method of claim 16 wherein said activating said 5 access to said real storage area includes providing a user 
token-accessible view includes translating said user virtual address in said first virtual storage area along with 
address into said real address and said system token. said user token t0 obtain a pointer virtual address in said 

18. A method of token controlled storage protection in a scoond st ^ 

virtual storage computer system having a real storage and a 22 ^ method of ^ 21 ^ 

virtual storage, said method composing: 10 m response tQ said requesting ^ to ^ 

creating,insaidrealstorage.arealstorageareawithareal said pointer virtual address correspondin g t0 said user 

address; virtual address if said user virtual address is within said first 

creating, in said virtual storage, a first virtual storage area virtual storage area and returning said pointer virtual address 

with a first virtual address and corresponding to said ^ to said user program, and generating a program exception if 

real storage area; said user virtual address is outside said first virtual storage 

creating, in said virtual storage, a second virtual storage area, 

area with a second virtual address and corresponding to 23. The method of claim 22 further including activating 

said real storage area and said first virtual storage area; said token-accessible view in response to said user program 

establishing a protected view and a token-accessible view 2 o requesting access to said real storage with said pointer 

from a user program to said real storage area via an virtual address. 

address translation means, including acquiring user and 24. The method of claim 23 further including creating an 

system tokens ^ corresponding to said first virtual storage isolating storage area contiguous with said second virtual 

area, and storing said user token in said user program; storage area, and establishing a protected view of said real 

an d 25 storage area with respect to the virtual address of said 

requesting access to said real storage area by providing isolating storage area. 

said user token via said user program. 25. The method of claim 24 further including generating 

19. The method of claim 18 wherein said establishing said a program exception in response to activating said protected 
token-accessible view includes providing a protected view view of said real storage via said virtual address of said 
of said real storage area with respect to said first virtual 30 isolating storage area. 

address and an unprotected view of said real storage area 

with respect to said second virtual address. ***** 
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